在開發系統時，難免都會碰到系統有問題必需回報給相關負責的單位。找到問題是好事，但不要在回報問題的時候反而功虧一簣。
用同理心想看看，如果有人回報問題時寫著
無法登入系統，請盡快排除問題
是否也會覺得黑人問號這是什麼狀況？
所以怎麼寫好問題，讓問題可以盡快排除而且賓主盡歡，也是一門學問。

提供測試的資料

提供資料跟在急診室做傷亡分類是一樣的，所以提供那個環境發生的？發現的時間？輸入的資料有那些？這些最基本的線索都很重要。愈詳細，問題來回的次數愈少。
例如
Report Date: 2002/09/29 Environment : Alpha URL: https://alpha/login Input: { "Id":"test20210028" }
如果是網頁的問題，最好附上是瀏覽器的版本號。
有些issue tracker可以輸入緊急程度和嚴重性，不要把每個issue都報「緊急」和「嚴重」，如果每個都緊急又嚴重那等於沒分類。就像前面說的，這是個醫檢的過程，所以適度的降低自己對這個問題的感受，用客觀的事實來描述問題。

重現步驟

真實故事：有一天客服跟我說我們的程式出了問題：原本可以用拖拉的方式把檔案放進應用程式的功能突然失效了，當時我還不清楚原因是什麼，但我下載了同一份應用程式，做了一樣的步驟都可以進行。
後來重新確認每一個步驟後才發現：如果使用者用Administrator開啟應用程式，拖拉的功能是會被封鎖的。所以我跟事主看起來雖然像是在同一個步驟上測試，但其實不然。
詳細的把每一個步驟都寫出來，多詳細呢？從打開瀏覽器開始，輸入網址，輸入每一筆資料，按鈕，導頁，錯誤。每一個步驟都有可能有問題，就像我前面的例子，差一小步可能都會導致問題發生。

預期結果

如果覺得這是錯的，那正確的情況是什麼呢？就像寫單元測試一樣，除了回報問題，也要有一個比對的對象。

Not your fault, it is me.

一個大家都聽過的笑話：如果直接把問題拋到對方身上，對方一定會想「屁啦這根本不是我的問題」，但如果回報時用另一個方法說「我不知道是不是我操作錯誤了，但我發現當我...的時候發生了...問題」，這通常都會讓開發人員心頭一緊覺得那裡又發生問題了。
經過我的實測，這在國外一樣有效。

用圖、影片做說明。

用截圖的方法說明，比文字說明更有用。如果可以加上影片或GIF圖更有效。

以上是回報問題的方法，每個團隊也許有更好的工具輔助，但其實使用的人更重要：就像Scrum Manifesto所說的

Individuals and interactions over processes and tools

所有的工具都無法取代人與人之間的溝通，要怎麼高效率的促使問題被解決才是重點。